AWS再入門ブログリレー2022 Amazon Application Load Balancer編

こんにちは、コンサル部のキム・ジェウクです。

当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の 15日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2022年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

15日目のテーマはAmazon Application Load Balancerです。

Load Balancingとは？

ELB (Elastic Load Balancing) は、アプリケーションへのトラフィックを、1 つまたは複数のアベイラビリティーゾーン (AZ) 内の複数のターゲットおよび仮想アプライアンスに自動的に分散します。

つまり複数のサーバが分散処理を行うのをLoad Balancingと言います。

では「Load Balancerって何だろう？」と考える方もいらっしゃると思います。 Load Balancerは、Load Balancing技術を提供するサービスです。

AWSでは三つのLoad Balancerサービスを提供しています。

• Application Load Balancer
• Network Load Balancer
• Gateway Load Balancer

OSI7 階層

Load BalancerはOSIの7階層で、どの階層を基準に分散作業を行うのかによって、サービスが異なります。

Application Load Balancerは「Layer7」であるApplication階層を使用し、URLまたはhttp-headerから負荷分散が可能です。

つまり、URLに応じて負荷を分散させたり、HTTPヘッダのCookieの値に応じて負荷を分散するなど、クライアントの要請をより細分化してサーバに伝達できます。

また「Layer7」Load Balancerの場合、特定のパターンを持つウイルスを検知してネットワークを保護でき、DoS/DDoS のような異常なトラフィックをフィルタリングできます。

Application Load Balancerの仕組み

1. クライアントはアプリケーションにリクエストを送信します。
2. ロードバランサーのリスナーは、設定したプロトコルとポートに一致するリクエストを受信します。
3. 受信リスナーは、指定したルールに対して受信リクエストを評価し、該当する場合、リクエストを適切なターゲットグループにルーティングします。HTTPS リスナーを使用して、TLS 暗号化と復号化の作業をロードバランサーにオフロードできます。
4. 1 つ以上のターゲットグループの正常なターゲットは、ロードバランシングアルゴリズムと、リスナーで指定したルーティングルールに基づいてトラフィックを受け取ります。

Private Subnet？Public Subnet？

初めてApplication Load Balancerを作成するときによく悩むのが、Private Subnetを選択するのか、Public Subnetを選択するのかの部分だと思います。

Application Load Balancerを作成するとき「スキーム」で「インターネット向け」と「内部」を選択できます。 ここでPublic Subnetを選択するのか、Private Subnetを選択するのかで、スキームが変わってきます

「インターネット向け」クライアントからインターネット経由でリクエストをターゲットにルーティングします。「内部」は、プライベート IP アドレスを使用してターゲットにリクエストをルーティングします。

Load Balancerを作成すると、選択したSubnetにLoad Balancer Nodeが作られます。 インターネットを通じてウェブサーバーにアクセスしなければならない場合、Private Subnetを選択してしまうとLoad Balancer NodeがPrivate Subnetに作られるため、外部と通信ができない状況が発生してウェブサーバーにアクセスできません。それで、自分の状況に合わせてSubnetを選択する必要があります。

Subnetは「マッピング」で選択できます。

「スキーム」で、「インターネット向け」 を選択すると、Public Subnet を選択する必要がありますが、Private Subnet を選択すると、警告メッセージが表示されます。逆に「内部」を選択してPublic Subnetを選択しても、警告メッセージが表示されます。

• インターネット向け : Public Subnet
• 内部 : Private Subnet

マッピング？

Load Balancerでもセキュリティグループを設定することができます。Application Load BalancerではHTTPあるいはHTTPSを設定します。

上記のイメージのようにSecurity Groupのinbound rulesでタイプをHTTPに設定して、ソースをAnywhereに選択すればいいです。

そして、作成したApplication Load BalancerのSecurity GroupをEC2 Security Groupのinbound rulesに追加します。

HTTPSも同じです。でも、HTTPSの場合「SSL証明書」が必要です。

リスナーでHTTPSを選択すれば下に「セキュアリスナーの設定」が現れます。ここでSSL証明書を選択できます。

ACMにSSL証明書を登録する方法は下のBlogを参考してください。

Application Load Balancerを通じしないとEC2には直接HTTP、HTTPS接続ができないです。

Target Groups

各ターゲットグループは、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます。

各リスナーのルールを作成するときに、ターゲットグループと条件を指定します。ルールの条件が満たされると、トラフィックが該当するターゲットグループに転送されます。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます。

ロードバランサーのヘルスチェック設定は、ターゲットグループ単位で定義します。各ターゲットグループはデフォルトのヘルスチェック設定を使用します。

health checks failed 問題

EC2にApacheがインストールされていなければ「health checks failed」というエラーが出てくる場合もありますので、EC2でApacheがインストールされているか確認する必要があります。

続いて、Apacheをインストールしたにもかかわらず、「Health checks failed with these codes: [403]」というエラーが表示されます。 このエラーは、現在ターゲットグループに登録されているパスにindex.htmlファイルがない場合に表示されるエラーです。

cp /usr/share/httpd/noindex/index.html /var/www/html/index.html

/var/www/htmlパスにApacheのindex.htmlを持ってきます。

もう一度Target Groupsを確認してみると「healthy」に変わっているのを確認できます。

おわりに

以上、『AWS 再入門ブログリレー 2022』の15日目のエントリ『Amazon Application Load Balancer』編でした。

次回、2/24(木)は枡川(masukawa)さんの「CodeDeploy編」の予定ですのでお楽しみにしてください！